fix(agent): stop inheriting superseded parent session denies in subagents - #45064

Issue for this PR

Closes #45078

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Session permission rules are append-only and evaluated last-match-wins, but deriveSubagentSessionPermission copies every parent-session deny into a task subagent, ignoring rule order. A parent whose rule history is [bash deny, bash allow] is effectively allowed — clients that implement plan-style restrictions append denies and later restore with allows, since PATCH is append-only — yet every new task child receives only the stale bash deny and is permanently blocked from bash even when its own agent policy allows it.

The fix filters the copied denies down to the parent's effective ceiling: a deny is dropped when a later rule targets the identical (permission, pattern) pair, because last-match-wins means that later rule, not the deny, is the parent's effective action for that key. This is deliberately conservative for partial overrides — a later allow with a different pattern (e.g. bash "git *" after bash "*" deny) does not drop the broad deny, so the inherited ceiling never widens beyond what the parent's own evaluation permits for the copied rule's exact pattern. external_directory inheritance and the default todowrite/task denies are unchanged, and the existing hard-ceiling behavior ([bash deny] alone still binds the child) is preserved.

How did you verify your code works?

• Added three tests to test/agent/plan-mode-subagent-bypass.test.ts (the suite that already exercises this production helper): a re-allowed deny is not inherited, a partially-overridden deny still is, and re-allowing one permission does not drop unrelated denies. bun test test/agent → 52 pass.
• bun test test/permission-task.test.ts test/session → 433 pass, 0 fail; tsgo --noEmit clean.
• Live end-to-end on a 1.18.22 deployment with this commit cherry-picked: a parent with appended [bash deny, bash allow] spawned a task child whose session ruleset contained no bash deny, and the child completed a bash command. Stock 1.18.22 reproduces the stale inherited deny.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR